One
of the benefits of having servers with multiple roles in Exchange is
that each role has its own type of functionality. This means the servers
can all be secured in a way that best suits their purpose. Securing
Exchange is a server-specific or role-specific process, but there is
also a common set of security practices across all Exchange servers. In
this section, you will discover how to secure different aspects of
Exchange servers.
1. Secure Client Access Servers
Client Access servers
(CASs) are potentially Internet-facing servers that your users use when
accessing their mail. An externally accessible CAS can pose a threat to
your organization. The primary method used for accessing the CAS
externally is web services. Therefore, it's important to lock down both
the server and the web services. The key items to secure the CAS role in
this capacity are the Secure Sockets Layer (SSL) certificates used for
Transport Layer Security (TLS) in the web services.
1.1. Configure a Certificate from a Certification Authority
Exchange Server uses
X.509 certificates for securing the communications of Client Access
servers. The web services used by the CAS should be SSL-enabled using a
certificate. By default, CASs have a self-signed certificate installed
that is valid for five years. This means that the CAS issues its own
certificate. Using the default self-signed certificate can work fine in
many instances. However, clients must trust the issuer of the
certificate to ensure that the certificate is valid. And since the
issuer of the self-signed certificate is the server itself, it is not
trusted by clients by default. Therefore, self-signed certificates are
difficult to deploy and manage in complex enterprise-wide deployments.
There are a couple of ways to deal with this situation:
Install the certificate into the list of trusted issuers on each client.
This method of
certificate deployment has some challenges. Also, you will need to issue
the trusted certificate for every CAS in your organization.
Obtain a new certificate from a certificate authority.
Obtaining a certificate from
a mutually trusted issuer—a certificate authority (CA)—is the more
accepted way to solve the problem. There are several well-known and
publicly trusted CAs that are trusted by default in Windows. Therefore,
any certificate that is issued to your Client Access servers by these
CAs is automatically trusted by your clients and considered valid. You
can also issue a certificate from a CA that your organization already
owns, instead of buying a certificate from a third party. In either
case, here are the steps for using a trusted certificate from a CA:
Install the certificate in Exchange.
Ensure that the clients trust the issuer.
1.1.1. Obtain a Certificate
When you obtain a
certificate for your Client Access servers, you will be required to
prove your identity to the certificate issuer. How this process works is
dependent on the issuer and will likely be different when you buy a
certificate from an Internet-based CA compared to using a CA that is
owned by your organization.
When you obtain your certificate, keep the following considerations in mind:
You should obtain either a wildcard certificate or a certificate that supports subject alternative names.
This ensures you can use the same certificate for verifying both
internal and external identities of the server. For example, the
internal name of the server may be contoso-cas1.corp.contoso.com, but the external name may be mail.contoso.com. You want the certificate to verify both identities.
If
the CA is not already trusted by your clients as a Trusted Root
Certification Authority, you should determine how much extra work is
needed to make it trusted. It may be worth using a publicly trusted CA
if your clients don't already trust the CA that you want to use.
You
should ensure that your servers contain the certificate revocation list
(CRL) specified on the certificate. This is typically done through
HTTP, but you many need to open access on your firewall depending on
your organization's security configuration.
To start the process of
obtaining a certificate, you will need to create a certificate request
from your Client Access server. This request will be stored in a file
with a specific format, and the file will be transferred to the CA that
is issuing you the certificate.
You must specify of the following in your certificate request:
The Various Names That the Certificate Will Be Used For
Make sure that you
include every name that clients will use to access the server when using
SSL. For example, they may use both CAS1 and mail.contoso.com. The issuer will likely have a restriction on the number of names that you can use.
The Name of the File That the Request Will Be Saved In
The certificate request is saved to a file that you can give to the certificate authority for generating the certificate.
The Subject Name of the Certificate
When creating your subject
name, ensure that the Organization name is the organization that owns
the domain namespace for the certificate. Your issuer will verify that
the organization owns the namespace before issuing your certificate.
When including the
alternate names in the certificate request, make sure that you include
all the potential identities of the server, including the names used for
AutoDiscover. When generating the request, you can use the IncludeAutodiscover parameter to automatically include the AutoDiscover Fully Qualified Domain Names (FQDNs) in the request.
|
|
You can create the
certificate request in the EMS using the New-ExchangeCertificate cmdlet.
When running this cmdlet, the DomainName parameter will be used to list
the FQDNs for the certificate's Subject Alternative Name field. You
will use the SubjectName parameter to specify the subject name of the
certificate. The output of this cmdlet is written to the screen, but you
will want to capture it to a file instead by piping the command to the
Set-Content cmdlet and specifying the name of the file. The following
example command shows you how to use the cmdlet to generate the
certificate request:
New-ExchangeCertificate -GenerateRequest -DomainName cas1,
mail.contoso.com -PrivateKeyExportable $true -SubjectName
"c=US, o=Contoso, cn=cas1.contoso.com" |
Set-Content -Path c:\cert.req
When you contact the certificate issuer to purchase your certificate, you must provide them with the information in the file.
1.1.2. Install the Certificate
Once you've obtained your
certificate from a trusted authority, you can install the certificate on
your Client Access server. You will receive your certificate in the
form of a file. To import the certificate, run the Import-Certificate
cmdlet in the EMS, as shown here:
Import-Certificate -Path c:\contoso.cer
When you create the
certificate request, the private key of the certificate is created
during the request and stored on the server where the request was
generated. If you want to use the same certificate on multiple servers
(such as in a lab environment), you will need to import the certificate
at the server on which the request was generated and then export the
certificate with the private key. You can then import the exported
certificate into other servers.
After importing the
certificate, you must enable the certificate on the services for which
your users will need to use a secure connection. On Client Access
servers, you will enable the certificate for IIS at a minimum. If you
are using IMAP or POP, you should enable the certificate for those
protocols as well.
To enable the certificate for the user services, you can use the Enable-ExchangeCertificate cmdlet. You will need the thumbprint of the certificate, which can be obtained from the Get-ExchangeCertificate cmdlet. The following command enables the certificate on CAS1 for IIS, IMAP, and POP services:
Get-ExchangeCertificate -DomainName CAS1 |
Enable-ExchangeCertificate -Services "IIS,IMAP,POP"
